\subsection{Cryptographic protocols}
\label{sec:design_crypto}

%\begin{figure}
%\centering
%\includegraphics[width=4in]{Images/crypto_ideal.png}
%\caption{Design of cryptographic attributes}
%\label{fig:crypto_ideal}
%\end{figure}

\begin{figure}
\centering
\includegraphics[width=4in]{Images/crypto_practical.png}
\caption{Design of cryptographic attributes}
\label{fig:crypto_practical}
\end{figure}

The cryptographic protocols used here have a few basic requirements.  The data are not confidential, and therefore can be stored in the clear.  The function of the cryptographic system then reduces to integrity.  This can be done with many methods, including symmetric/asymmetric keys, encryption, hashing, etc.

Because this system is intended to eventually operate as a reference monitor within the kernel, the history log need be accessed by a single entity.  To be secure, the module must maintain some secret, and this can just as easily be used as a key.  Therefore using an asymmetric key pair does not match the task, and adds awkward overhead, so symmetric key techniques are used throughout.  This has the added benefit of opening the possibility of tying the OS-level monitor to a trusted hardware platform by ensuring the key within the TPM.

The actual structure of the protected log is shown in Figure \ref{fig:crypto_practical}.  The log can only be modified by extending it, so successive entries are added at the end.  Each row in the log entry is integrity protected using an HMAC.  The log must be associated with a specific location, so the canonical path to the object is included as a row.  To avoid having to read the entire file to figure out how many attributes are present, a count is also included.

The header is completed with a parity field.  This parity is of the actual values themselves, as the field for an attribute is fixed-width at 32 bytes (256 bits).  This parity protects the overall log against addition or deletion of a row.  Parity was chosen as a measure that can be extended without recalculation over the entire set of attributes.  Thus adding an attribute requires reading only the header attributes.

%It takes plain attribute, encrypt it by using public key encryption, integrity protects it and raise it as an extended attribute on file system.

%What about simply replacing the file?  Does the xattr stay?


